feat(mobile): rebuild the chat tab on the harness SDK - #5895

The tab keeps its label and its icon and gains a beta pill. Behind it is a
new surface: a list of chats, and one screen per conversation that runs on
the device through the harness SDK rather than through a server session.

A chat is not tied to its screen. The live sessions live in a module
registry, so a person can ask something, leave for another tab, and come
back to the answer, and several chats can be answering at once.

The layering is the point of the split:

- The SDK's store saves one conversation and reads it back.
- The app owns everything about many of them: the list, the title, the
  order, the delete, the scope per account and organization, and the wipe
  on sign-out. That is SQL in `lib/chat/store.ts`, over both owners' tables
  on the one encrypted database.

Switching models mid-conversation clones the session onto the new model and
moves the chat row onto it, so one conversation stays one row. A question
whose answer never arrived is remembered outside the store and drawn with a
Retry, because the store writes a question and its answer together or
neither.

Everything here came out of running the tab against the real gateway on a
simulator.

React Native has no global `crypto`, so the SDK's default entropy raised on
the first session. The app supplies expo-crypto, which is what already
encrypts the database. The SDK's store creates its tables when its layer is
built, so a list drawn before any chat had ever opened read tables that did
not exist; the list asks for the runtime first. A failed answer logged
nothing, because an Effect cause carries its own text and this package's
errors carry their fields — the failure value is read instead. The header
drew no title, and the composer kept the text it had sent.

The list is read from the database, and a chat writes its turns when its
answer ends. Nothing told the list that had happened, so a chat started from
the list kept the row it was given: no title, because the title is the first
thing said in it. The registry now says when a chat starts or stops working —
not on every word of an answer — and the list reads the database again,
whichever screen the answer arrived on.

FlashList holds the scroll position when content is added at the top, which
is right for a transcript and wrong for a list of chats newest first: the new
row went above the top of the list, behind the header.

apps/mobile typechecks against the built package, the way it already does
against trpc. The build now runs in the same place, under the same rule.

The mobile suite opens the SDK's store against the real schema, so it needs
the built package the same way the typecheck does.

Four things the review found, all in what a person sees while a chat works.

The question being answered was hidden until its answer landed: the screen
passed it to the transcript only when the chat was idle. It is passed always
now — the screen hands over the whole state and decides nothing.

A second question sent while an answer arrived started a second read of the
same session. The composer is deliberately open while the model works, so this
is ordinary: the question now joins a line, is drawn where it will be asked,
and is asked when the session is free. Stopping an answer moves the line on;
a failed one holds it, because that question keeps the Retry.

A question whose send failed before the model saw it vanished with the
composer's text. It now stays on screen with a Retry under it, the same as one
whose answer never arrived.

An account signing in over another left the first account's chats running.
They are ended, before the account's cache is cleared. The rows stay, scoped
to the account that made them, exactly as the read cache on disk does.

The registry outgrew one file: what a chat looks like is now its own, so the
registry is only what drives one.

Two things the line got wrong, both found by review.

Closing a chat went through the stop, and the stop asks what is waiting. So
signing out, or deleting a chat, opened a round on a session whose scope was
closing under it. The interrupt is now its own step: a chat that is stopped
asks the next question, a chat that is closed drops it.

A question typed while an answer arrived was asked on whatever model the
session was on by then. It is asked on the model that was on screen when it
was typed, which is what the person picked.

The registry has its first tests: the SDK is faked, because none of this is
about the SDK.

A chat is a session of a plainer kind, so it now looks like one. The row is
the SessionRow every other list uses: the model names it and colours its
strip, the same live dot marks an answer still arriving, and the rows run
edge to edge with one hairline between them.

The header loses the context control and the corner button. Starting a chat
is the floating button the sessions list already puts in that corner, and it
stays out of the way of an empty list, which carries its own.

A conversation puts its composer where the tab bar sits, so the bar goes
while one is open, the way it already does for the other full-screen routes.
The composer then sits on the home indicator instead of on the bar that is
no longer there.

The rule reads the route segments rather than the path: a conversation's path
is the session id and nothing else, which no path rule can tell from any
other one-segment route.

A model has no clock. Asked what day it is, how old something is or whether
a deadline has passed, it answers from the date it was trained on, with the
same confidence it says everything else and no sign that it has moved. A
phone is where that gets asked.

So every chat is opened with the SDK's time tool, reporting local time in
the zone the device is set to and UTC beside it. The system prompt stops
claiming there are no tools and says to read the clock rather than assume it.

The other three tools the SDK ships stay off: the composer is already how a
person is asked something, a subagent costs a second session, and a to-do
list is working memory for a long run a chat does not have.

The eleven models the SDK's live runs use are the ones a chat change is
proved against, and the model picker's accessibility tree is what takes the
Appium server down when a run reads it whole.

…uestion

Two things a question could fall through.

A question typed before `enterChat` finished found no chat, and `say` returned
the identifier it was given as though it had asked. The composer had already
emptied, so the question was gone with nothing on screen to say so. It now
waits for the open, and a chat that is genuinely not there raises rather than
reporting success — which puts the question back on screen with a Retry under
it, the same as one whose answer never arrived.

A queued question asked on another model clones the conversation, and `drain`
ignored the new identifier: the transcript moved to a session the screen was
not watching. The chat that was left now points at the one it became, and
`useChat` follows that, so `say` and `retryChat` hand nothing back. The screen
is not always the mover, which is why the return value was the wrong seam.

…/mobile-harness-chat

Main added common.chat, common.working, common.delete, common.message and
common.couldNotLoadModels while this branch carried its own wording for the
same English. The catalog check holds one wording per string, so the chat
screens now read the shared keys and the duplicates are gone from all 87
catalogs.